Funds transfer method and system

ABSTRACT

A funds transfer method in a communications system between two entity computers where, depending on the transaction, one is remitter computer and the other is a recevier computer. There is a systems server computer associated with an escrow account. Once a transaction has been agreed between the two computers, the systems server computer sets aside the funds in the escrow account, which funds are no longer available to the remitter computer which will often be operated by a buyer in the internet. Then the systems server computer issues two codes, namely, an initial initiation code and a funds release code respectively. The initiation code is sent to the receiver computer as confirmation of the availability of the funds in the escrow account. The other funds release code is with the remitter computer which sends the code to allow release of the funds on completion of a specified event occurring such a expiry of an agreed settlement date, acceptance by the remitter that the trade to which the transaction relates was satisfactorily completed or indeed any other agreed outcome. The invention allows for negotiations to take place between the parties, if a dispute should arise by postponing the expected settlement data until, if no resolution of the dispute can be found by negotiation between the parties, a formal alternative dispute resolution procedure is set up.

The present invention relates to a funds transfer method in a systemcomprising a plurality of entity computers and a system server computerInterconnected, by a communications network.

Secure transfer of funds is required in many situations but particularlyin situations where the parties are remote and do not meet face to faceto complete a transaction. The transaction can be a very simplefinancial transaction, for example, a parent transferring funds to achild in some other jurisdiction or transferring funds to somebody elsein another jurisdiction or indeed at a remote location within the samejurisdiction. The person transferring the funds and the person receivingthe funds always have considerable problems as to the security of thetransfer. A further problem arises where there is actual trading takingplace between a buyer and seller. Then the transaction is part of alarger or more complex commercial transaction. Very often, the buyer hasto transfer funds before the goods are received, the seller beingobviously reluctant to send the goods without receiving payment. At thesame time, the buyer is often unaware as to the merchantable quality ofthe goods being purchased, particularly where they have to be delivered,or indeed, as to the service, for example, where the service can bedelivered on line. There is thus, in effect, a reluctance for the buyerto trust the seller to provide the goods or services to the quality andstandard required and the seller is equally reluctant to provide thosegoods or services until he or she has been paid. This is a major problemwhere the buyers and sellers are unknown to each other or where neitherof them have an established trading or credit record. Internet auctionsites are a particular example of this.

There are many existing numbers of solutions to these problems such asthose sold under the Trade Marks PAYPAL, C2IT and BILL PAY. The problemis that these systems suffer from a high level of disputes related toeither a commercial dispute between the parties or fraudulent activityby either of the parties. These disputes result in high costs to thesystem, that is to say, to the operators of the system, to resolve them.

The present invention is directed towards overcoming these problems andin particular to a more flexible system which would allow parties to acommercial agreement an opportunity to resolve such disputes betweenthemselves prior to resorting to litigation or other third partyoperated dispute resolution.

STATEMENTS OF INVENTION

According to the invention, there is provided a funds transfer method ina system comprising a plurality of entity computers each with means toprovide an unique entity identification (ID) and a system servercomputer interconnected by a communications network, the system servercomputer having an escrow account associated therewith into and out ofwhich funds may be transferred, the method comprising establishing,prior to or during a funds transfer, an entity account for each entitycomputer with the system server computer and on a funds transfer beingdesired between two entity computers, designating, as appropriate, oneas a remitter computer and the other as a receiver computer and then thesteps are performed of:

-   -   the remitter computer sends transaction details and the receiver        entity ID to the system server computer;    -   the systems server computer confirms the availability of funds        in the escrow account for the receiver computer entity account,        which funds are no longer available to the remitter computer;    -   then, on a specified event occurring, the funds are released        from the escrow account to the entity account of the receiver        computer.

The advantage of this is that the receiver computer, having the funds inescrow, increases the possibility that the transfer of funds will takeplace and if the transaction is conducted in a correct and timely mannerby the receiver, that is to say, the seller of the goods or services,the funds will be received. At the same time, the buyer or remittercomputer has the comfort that they will not be released until aspecified event occurs which will have been previously agreed betweenthe remitter computer and the receiver computer.

In one way of carrying out the invention, the method comprisesgenerating two different codes, namely, an initial initiation lockingcode and a funds release code, in which the locking code is used tocontrol the holding of the funds in the escrow account and the fundsrelease code is used to control the release of the funds from the escrowaccount. This is an extremely efficient and easy way of carrying out thesystem.

With this use of two different codes, on the system computer confirmingthe availability of the funds in the escrow account, the system computersends the initiation locking code to the remitter computer asconfirmation of the availability of the funds in the escrow account forthe receiver computer entity account and the funds release code to theremitter computer and on the specified event occurring, the fundsrelease code is sent to the system server computer and the system servercomputer releases the funds from the escrow account to the receivercomputer entity account. Alternatively, on the system server computerconfirming the availability of the funds in the escrow account, thesystem server computer sends the two codes to the remitter computer andif the remitter computer does not send the initiation locking code tothe other entity but sends it to the systems server computer, thetransaction is cancelled and the funds in the escrow account arereleased to the remitter entity account

In one embodiment of the invention, the sending of the funds releasecode to the system server computer comprises:

-   -   the remitter computer sending the funds release code to the        receiver computer; and    -   the receiver computer sending the funds release code to the        system server computer.

The specified events can comprise one or more of:

-   -   the expiry of an agreed settlement date;    -   the receipt by the receiver computer of acceptance of completion        of the transaction;    -   a prior agreed condition precedent for completion of the        transaction being achieved;    -   a mutually agreed outcome notified by the two entities to the        systems server computer; and    -   a decision by an arbitrator appointed to resolve the dispute.

The establishment of an entity account for a remitter computer isaccomplished by the transfer of funds to the escrow account.

In one embodiment of the invention, during the transaction, the receivercomputer sends notification of completion of the transaction to theremitter and system server computers and if the remitter computerdisputes the satisfactory completion of the transaction prior to anexpected settlement date, the steps are performed of:

-   -   the remitter computer sends a revised settlement date to the        system server computer;    -   the two entity computers enter into dispute resolution        negotiations; and    -   if, on expiry of the revised settlement date, a satisfactory        resolution of the negotiations has not taken place with the        release of the funds in the escrow account to one or both of the        entity accounts:    -   the systems server computer establishes an appropriate formal        alternative dispute resolution (ADR) procedure.

This allows the parties to the transaction, namely, the remittercomputer and the receiver computer to engage in negotiation withoutinvolving the system server computer, which negotiations can beconducted with the comfort of both parties, that the funds are held inescrow. This will also avoid a considerable number of difficultiesbetween parties when relatively easily solved events have occurred; suchas, for example, a delay in delivery due to difficulties with postal orother delivery services, damage to the goods in transit, or what isoften the more likely happening, in that there has been amisunderstanding between the parties. As will be well appreciated, inmany situations between buyer and seller, the buyer, when he or shereceives the goods, finds that they are not exactly what they requireand they wish to return them. The seller may be quite willing to acceptthe return and, with the present invention, this can be carried outwithout any great difficulty between the parties. Similarly, sometimesgoods are substituted for other ordered and unavailable goods when theseller believes they would be satisfactory and they are not. There aremany situations that anybody will appreciate which arise in any tradewhere the two parties are acting perfectly honourably and honestly, butthe transaction is unsatisfactory to one or other of the parties. Insituations like that, It is very often the receiver of the goods orservices who is unhappy with what has been done. Therefore, insituations such as this, the parties have an opportunity to, resolve thematter between themselves, without involving any third party, althoughthere is still the possibility of third party intervention.

Very often, on the revised settlement date expiring, a new revisedsettlement date is set to allow negotiations to continue and indeedafter a preset number of revised settlement dates have expired, the ADRprocedure is initiated unless both entity computers agree to the settingof a further revised settlement date.

It is also preferable that the system server computer records:

-   -   the number of transactions for each entity computer whether        acting as a receiver computer or a remitter computer, the        reception of a revised settlement date for each transaction for        that receiver or remitter computer as a default transaction; and    -   where the number of default transactions exceed a preset limit,        the system server computer remotes the entity computer from the        system.

Further, the system server computer records:

-   -   the number of transactions for each entity computer, acting as a        receiver computer or a remitter computer;    -   the establishment of ADR for each transaction for that receiver        or remitter computer as a default transaction; and    -   where the number of default transactions exceed a present limit,        the system server computer removes the entity computer from the        system.

In one embodiment of the invention, the preset limit is one or more of:

-   -   a number of default transactions in a specified period;    -   a percentage of the total number of the transactions within a        specified period being default transactions.

In this way, the system server computer has control effectively over theentities involved in the system. It should, very quickly, be able toeradicate rogue or unsatisfactory sellers of goods and services becausethese receiver computers would be involved in a large number of disputeswhich would allow the system server computer to drop that entitycomputer from the system. The same would apply with those purchasers ofgoods and services acting as remitter computers who were seen to behavein an unsatisfactory manner. It would be relatively easy for therecording of such events to enable the systems server computer todecline to handle transactions for that entity computer.

Further, the invention provides a funds transfer method in a systemcomprising a plurality of entity computers each with means to provide anunique entity identification (ID) and a system server computerinterconnected by a communications network, the system server computerhaving an escrow account associated therewith into and out of whichfunds may be transferred, the method comprising establishing, prior toor during a funds transfer, an entity account for each entity computerwith the system server computer and on a funds transfer being desiredbetween two entity computers, designating, as appropriate, one as aremitter computer and the other as a receiver computer in which thesystems server computer and/or the receiver computer are outside thejurisdiction, and then the steps are performed of:

-   -   the remitter computer sends transaction details and the receiver        entity ID to the system server computer;    -   from the systems server computer, the remitter computer receives        confirmation that the receiver computer has been notified of the        availability of funds in the escrow account for the receiver        computer entity account which funds are no longer available to        the remitter computer;    -   then, on a specified event occurring, the remitter computer        receives confirmation that the receiver computer has had the        funds released from the escrow account to the entity account of        the receiver computer.

Again this method may be handled in substantially the same way asdescribed above.

In a further method according to the invention, there is provided afunds transfer method in a system comprising a plurality of entitycomputers each with means to provide an unique entity identification(ID) and a system server computer interconnected by a communicationsnetwork, the system server computer having an escrow account associatedtherewith into and out of which funds may be transferred, the methodcomprising establishing, prior to or during a funds transfer, an entityaccount for each entity computer with the system server computer and ona funds transfer being desired between two entity computers,designating, as appropriate, one as a remitter computer and the other asa receiver computer when one or both of the entity computers may beoutside the jurisdiction and then the steps are performed of:

-   -   from the remitter computer, the systems serer computer receives        transaction details and the receiver entity ID;    -   the systems server computer confirms the availability of funds        in the escrow account for the receiver computer entity account,        which funds are no longer available to the remitter computer;    -   then, on a specified event occurring, the funds are released by        the systems server computer from the escrow account to the        entity account of the receiver computer.

As remarked already, substantially the same way of handling thesetransactions can be carried out, as described above.

It is envisaged that the method according to the present invention maybe carried out by providing a computer program comprising programinstructions for causing a computer to carry out some or all of themethods described above. Such a computer program may be embodied on arecord medium, a computer memory, a read-only memory or carried on anelectrical signal carrier.

The invention is also directed towards providing a computer programmedto carry out some or all of the method as described above.

DETAILED DESCRIPTION OF THE INVENTION

The invention will be more clearly understood from the followingdescription of some embodiments and examples thereof, given by way ofexample only, with reference to the accompanying drawings, in which:—

FIG. 1 is layout of a system in which the invention could be carriedout; and

FIGS. 2 and 3 are a flowchart of one method of carrying out theinvention.

Referring to the drawings, there is provided a communications network 1indicating a plurality of computers, namely, entity computers 2 and asystem server computer 3. The system server computer 3 has associatedtherewith a plurality of entity accounts 4 and an escrow account 5.

In operation and dealing firstly with a simple trading situation betweena buyer and a seller where the buyer wishes to buy certain goods and theseller agrees to provide them, in this particular system, there isagreed an arbitration system. The two entity computers are correctlydescribed as buyer and seller computers when referring to the purchaseof goods and/or services. However, when considering the financialtransaction taking place between the two entities, it is more proper todesignate them respectively as receiver and remitter computers. Theterms are used interchangeably throughout the specification. It shouldalso be appreciated that the terms “buyer/seller” or “remitter/receiver”are references to the role of the computers within the system, as anentity computer in one transaction might be a buyer or remitter and inthe next, a seller or receiver.

Referring to FIGS. 2 and 3 there is illustrated a very simple layout ofone trading operation. In step 1, the buyer computer agrees a price withthe seller computer and in step 2, the seller computer provides a systemaccount number to the buyer computer. Needless to say, this could be anyother suitable reference other than an account number such as an emailaddress, trading code, and so on. This is a normal standard referencewhich would normally be used in a trading situation and must not beconfused with the codes used in the invention. The buyer computer, instep 3, lodges money or causes money to be transferred from the buyersentity account, if the buyer has one, or in any case, to an escrowaccount. In step 4, the funds are received in the escrow account andheld in the escrow account. These funds are not available to either thebuyer or the seller computers at this stage.

In step 5, the buyer computer receives two codes from the system servercomputer, namely an initial initiation locking code and a funds releasecode for simplicity hereinafter called bodes A and B. In step 6, theremitter computer sends code A to the receiver computer. In step 7, thereceiver computer provides code A to the system server computer whichlocks the funds for the benefit of the receiver. In step 8, havingreceived code A which informs the receiver computer that the funds arebeing held in escrow, the seller sends the goods to the buyer. It willbe appreciated that these could be simply services over the internet orthe like such as the downloading of music by the seller computer. Instep 9, the buyer receives the goods and the buyer then, in step 10,checks the goods. Presuming the goods are acceptable, then in step 11,the remitter computer sends code B to the receiver. Then, in step 13,the receiver computer sends code B to the system server computer and instep 14, the funds are transferred to the receiver entity account and instep 15, the remitter computer is informed that the funds have beenreleased from escrow to the receiver account and in step 16 thetransaction is complete.

If, however, the buyer has not accepted the goods, then in step 12, theremitter computer enters a revised settlement date and then enters intonegotiations and other discussions with the seller and in step 17, thedispute has either been resolved or not if it has been resolved, step 11takes place and the remainder of the operation is as described above.If, however, this dispute has not been resolved, then step 12 isrepeated by the remitter computer-entering another default date. Thismay occur a fixed number of times, each time repeating steps 12 and 17until either the dispute has been resolved or not. If it has not beenresolved, then the system server computer initiates arbitration in step18 and the arbitration is carried out in step 19. Then, arbitration isconcluded in step 20 which means that the matter has been resolvedbetween the buyer and seller and the remainder of the trade takes place.Thus steps 11, 13, 14, 15 and 16 are carried out. If, however, thearbitration, when concluded, does not mean that the trade continues,then in step 21, the transaction is cancelled, in step 22 the funds arereleased to the remitter entity account and then step 16 is carried outto end the transaction. As mentioned above, instead of using arbitrationafter a certain number of defaults, step 21 may take place withoutarbitration and the transaction cancelled.

In its simplest, a buy/sell situation uses two codes and essentially adeal is agreed as in any situation, the seller provides the buyer withan account reference number, the buyer makes an escrow payment to thesellers account for the agreed value and the buyers account is in someway debited. If the particular remitter computer has an entity accountalready established, then that entity account is debited. Alternatively,the remitter computer arranges to transfer the funds to the escrowaccount. In the normal operation of the account, the system will providethe remitter with two codes (codes A and B) and generally, the remitterwill give one of these codes (say, code A) to the seller immediately viaemail, telephone or so on. Then, the receiver calls up the transactionwithin his own account established with the system and enters this firstcode. Generally speaking, the system will inform the remitter, viaemail, that the receiver computer has entered this first code. The fundsare now in escrow and are not available to either party. The remittersaccount has indeed been debited but the sellers account has not beencredited. Once the receiver has delivered the product or service asagreed, then the remitter gives the second code (code B) to the receiverand the receiver calls up the transaction within his system account orentity account and enters the code which then causes the system computerto release the funds and credit the account of the receiver computer.Thus, the transaction ends.

Needless to say, when, for example, the deal is concluded and thepayments have been made, the goods are delivered and the buyer doesnothing further. The second situation can arise where the buyer changeshis or her mind, after making the payment to the escrow account butbefore the seller has entered code A and delivered it to the systemcomputer. In another situation, the delivery is not made, made partiallyor the goods or services are unacceptable; in this case, the remittercomputer does not send the second code, i.e. the funds release code, tothe receiver computer until the problem has been resolved.

It is envisaged that there are many ways in which the process may becarried out. For example, when the remitter computer initially sends thefunds to the escrow account, an expected settlement date may be enteredwhereby the receiver is notified that in the event of failure of theremitter to contact the systems server computer, the funds will bereleased. Effectively, this is a default date. Then, the system computerwill automatically release the funds to the receiver when this defaultdate has passed unless the remitter computer has intervened.

It will be appreciated that the buyer computer can intervene in theprocess in many ways. Firstly, the remitter computer could intervenebefore the receiver computer has entered this code A, i.e. theinitiation locking code. The remitter can then enter code A and cancelthe transaction. The funds are returned to the remitter's account andthe receiver is informed of a cancellation. This can only happen whenthe remitter computer has received both codes and the receiver computerhas not yet received code A which will be used as a trigger to supplythe goods and services. Therefore, effectively, the whole operation iscancelled prior to initiation.

Before the expected settlement date, the remitter can enter code B thatin this case, releases the funds immediately to the receiver's accountand then the receiver computer would normally be informed.Alternatively, before the receiver entity has entered code B and beforethe expected settlement date, the remitter computer can enter code B anddefer the expected settlement date, for example, up to seven days. Thereis thus provided a revised settlement date. This caters for situationswhere a delivery has not been completed or some discussion is takingplace between remitter and receiver and time is needed to resolve it.The receiver computer would then be notified of the extended or revisedsettlement date which is effectively a default date from the systemserver computer. Needless to say, this deferring of the settlement dateby a revised settlement date can be carried out a number of times and itdepends how many times are agreed, for example, in the system. It could,for example, normally be three. At some stage, however, the remittercomputer may enter code B with the resultant immediate release of thefunds unless some form of dispute resolution has been initiated. Thiscan either be initiated automatically or alternatively, can be initiatedby a positive action on behalf of the remitter computer. Needless tosay, once this has happened, either the two parties can resolve itthemselves or the transaction can be referred to automatic disputeresolution and arbitration.

An essential feature of the invention is that some specified eventoccurs which allows the funds to be released. The specified event can bean expected settlement date which can be agreed between the parties. Itmay, for example, be a condition of sale provided by the seller, namelythat the settlement date must be adhered to. Obviously, the systemallows for this to be extended, but can only be extended by the remittercomputer actively doing so. There are other specified events that may berequired or could be used. For example, the event could be the receiptby the receiver computer of acceptance of completion of the transactionfrom the remitter computer. It will be appreciated that there would beno need for the remitter computer to delay acceptance because the moneyis already in escrow. Alternatively, the specified event could be aprior agreed condition precedent for completion of the transaction. Thiscould, for example, be buyer inspection, It could be some other thirdparty inspection or passing of the goods by an official authority suchas, for example, the delivery of a yacht and the need to have itsmeasurement certificate certified. It might also be the requirement thatthe goods be passed fit for human consumption, and so on. Indeed, itwill bo appreciated that the two entitles can have any mutually agreedoutcome which may be notified by the two entities to the system servercomputer as the specified went, namely, the condition precedent for thedelivery of the good.

Finally, as will be described below and discussed in more detail, thespecified event could be a decision by an arbitrator in the event ofmediation between the parties not succeeding.

The following are some examples as to how the process according to theinvention may be initialled.

EXAMPLE 1 Remitter Knows Receiver and has his Account ID

-   -   1. The remitter provides funds, an expected settlement date        and/or some other condition for the release of funds and the        receiver account identifier to the system server computer    -   2. The system server computer provides code A and code B to the        remitter computer    -   3. The remitter computer provides code A to the receiver    -   4. The receiver computer provides code A to the system server        computer, which causes the funds to be locked for the benefit of        the receiver entity account.

EXAMPLE 2 Remitter has No Account ID of Receiver

-   -   1. The remitter provides funds and an expected settlement date        to the system server computer    -   2. The system server computer provides the transaction        identifier and the initiation locking code A and code B to the        remitter computer    -   3. The remitter computer provides the transaction identifier        code A to the receiver computer    -   4. The receiver computer provides code A the transaction        identifier and his account identifier, i.e. his entity account,        to the system server computer, which causes the funds to be        locked for the benefit of the receiver.

EXAMPLE 3 Receiver does not have Remitter Details

-   -   1. The receiver computer provides the details of the transaction        including his account identifier to the system server computer    -   2. The system server computer provides a transaction identifier        to the receiver computer    -   3. The receiver computer provides the transaction identifier to        the remitter    -   4. The remitter computer provides the transaction identifier,        funds and the expected settlement date to the system server        computer    -   5. The system server computer provides code A and code B to the        remitter    -   6. The remitter computer provides the code A to the receiver.    -   7. The receiver computer provides the code A to the system        server computer, which causes the funds to be locked for the        benefit of the receiver.

In the event that the transaction is completed to the satisfaction ofboth parties there are three possible courses of action.

The remitter computer provides code B to the system server computer withthe instruction to release the funds to the seller.

The remitter computer provides code B to the receiver computer.

The receiver computer provides code B to the system server computer withthe instruction to release the funds to the receiver.

The remitter computer does nothing and the funds are released to theseller on the expected settlement date.

In the event that the transaction is not completed to the satisfactionof the remitter.

The remitter provides code B to the system server computer with theinstruction to put back the expected settlement date. This may be done anumber of times in order to provide a period of time to complete thecommercial transaction if it is taking longer than expected or toresolve a dispute between the parties.

Should it not be possible to resolve the dispute either within themaximum number of times the date can be put back or by the choice of theremitter, the remitter on providing code B to the system server computermay elect to send the dispute for arbitration.

It will be appreciated that when there are funds only being transferredbetween the parties without the delivery of goods or services being acondition precedent therefor, it will be relatively simple for onecomputer to transfer to another entity computer by simply downloadingreceiver ID and receiving a code from the system server computer. Untilthe receiver computer is informed by the system server computer thatthere are funds available, the funds are kept in escrow. Once thereceiver computer identifies that the funds are available for him orher, then the receiver computer can inform the remitter computer and theremitter computer can then dispatch code B, either itself to the systemserver or to the receiver computer for onward transmission. In this way,the remitter can be confident that the funds are being delivered to theright person.

There are certain major advantages with the invention. Firstly, if, forexample, a seller is involved in a considerable number of disputes ordisagreements with buyers, the systems operators will immediately becomeaware of this and if can be logged into the systems server computer,such that the systems server computer can refuse to deal with aparticular seller or receiver. This will give considerable security to abuyer, since the system will ensure, in most cases, except betweenprivate individuals, that the entities are vetted in some way, if not onacceptance by the system, by their performance as they use the system.

There is also a great advantage for the buyer, particularly where thebuyer does not know anything about the seller because the escrow accountcan be used to protect the buyer. At the same time, the escrow accountoperates automatically such that with the provision of varioussettlement dates, most of the dispute of disagreements between buyersand sellers can be readily easily handled. In many instances, it will beappreciated that most of the problems that arise will often be problemsdue to wrong specifications of goods, delays in delivery of goods, Inability to furnish all the goods, and so on. By having the presentsystem, these will be largely overcome. This is not to say that disputeswill not arise, however, the system will automatically ensure that alarge number of disputes do not occur. There will be sufficient time,one could almost describe it as a “cooling off” time within which theentities will be able to resolve their differences to their mutualsatisfaction.

It is envisaged that arbitration, which will be a last resort, will notbe used that often.

The innovative feature of the invention can be summarized as follows:

-   -   1. The remitter provides funds to the escrow account    -   2. The system server gives the two codes to the remitter    -   3. Until the receiver enters the first code, these funds may be        retrieved by the remitter    -   4. The receiver gets code A and he provides this to the system        server    -   5. The funds are now locked to the benefit of the receiver but        he cannot access these funds until code B has been provided    -   6. An event occurs that concludes the transaction (goods are        received by the remitter)    -   7. Provided the remitter is happy, he provides code B to the        receiver    -   8. The receiver then enters code B and he then has access to the        funds.

The above is the simple situation with no problems.

However, when a problem arises, one way of solving it, described herein,can be summarized as follows:

-   -   1. The remitter is not happy with the goods    -   2. The remitter may enter code B and signal the existence of a        problem to the system server and the server or remitter will        select a resolution date by which the problem should be resolved    -   3. The system server informs the receiver (or not, as the        remitter may do this) of this action by the remitter (this        provides a breathing space for the two parties to sort out the        problem)    -   4. The remitter will be permitted a fixed number of times that        the resolution date may be extended    -   5. Only after the parties have failed to resolve the problem        themselves, dues this system start the arbitration process.

When reference is made to alternative dispute resolution (ADR) in thisspecification, the reference is made to refer to all forms of disputeresolution and under various arbitration or other mediation rules. It isenvisaged that the system severer computer would have available to it anumber of such systems and would choose the one most appropriate to theparticular circumstances.

One of the great advantages of the present invention is that there is,generally speaking, an onus on the parties to resolve the dispute. Thereis no advantage to the remitter in not releasing the funds because thefunds are not available to the remitter. There is an onus on thereceiver to quickly satisfy the remitter so that the remitter will allowthe release of the funds.

One of the advantages of the present invention is that by allowing theparties to negotiate and do everything possible between themselves toresolve the dispute, the operators of the system are not involved in thedispute. Since the system will only be available to those entities thatagree to join the system, there is a degree of control over the users ofthe system. This particularly relates to those who would normally beselling goods and services and receiving remittance of funds in thisway. If a particular merchant entity using the system is involved in alarge number of disputes, then the system server computer has a recordof these and, if necessary, can drop that particular entity from thesystem and disconnect the entity computer from the system. This means,for those entities that are normally buyers within the system, that theyhave some degree of confidence in the merchants or traders using thesystem. There is, while not necessarily a guarantee from the system ofthe probity of an entity trading therein, there is a presumption of it,and this presumption can be reasonably made by a buyer, that such anentity will operate in a reasonable way. There will also be apresumption for those entities who normally act as receiver computers,that the people they are dealing with will honour their financialobligations. As far as the merchants or sellers are concerned, havingthe funds automatically in escrow is of considerable comfort. This isparticularly important for those entities selling relatively low costitems. Whether these items be downloaded directly between entitycomputers or whether they result in the receiver entity computer, whenacting as a seller, having to send goods to the other entity. If theactual monetary value of the transaction is low, it then becomesuneconomic for the provider of those goods and services to engage in anyform of litigation.

It will be appreciated that the nature of the present invention is suchthat as a matter of course, many of the tasks required to carry out theinvention will be performed outside the jurisdiction, and possibly inmany jurisdictions. Thus, where it is stated that a particular actionis, or actions are, performed, it may be that only the end result of theaction may be delivered into the jurisdiction. Thus, for example, thesystem server computer may be considerably geographically remote fromone or both of the entity computers. Accordingly, all that may becarried out within the user computer is very few steps of the invention.However, such steps cannot be performed without the availability of thedata transmitted to or from it with the other computers.

Therefore, it is submitted that the appended claims be interpreted notliterally but having regard to this circumstance and that the carryingout of some of the steps of the invention within the jurisdictioncovered by any patent for onward transmission of the results of thecarrying out of those steps shall be deemed to be infringement withinthe jurisdiction in the sense that delivery into or receipt within thejurisdiction of the results of some steps of the method carried outoutside the jurisdiction be deemed to be the same as of the steps hadbeen carried out within the jurisdiction.

Accordingly, a statement that a particularly computer carries out aparticular task is deemed to cover not alone the carrying out of thetask or operation within the jurisdiction but also the carrying out ofthe task outside the jurisdiction and the delivery of the result of thecompletion of the task to within the jurisdiction and the actionrequired within the jurisdiction is the reception of the result of theaction carried out outside the jurisdiction.

In the specification the terms “comprises, comprised and comprising” orany variation thereof and the terms “include, includes, included andincluding” or any variation thereof are considered to be totallyinterchangeable and they should all be afforded the widest possibleinterpretation and vice versa.

The invention is not limited to the embodiment hereinbefore describedbut may be varied in both construction and detail.

1-51. (canceled)
 52. A funds transfer method in a system comprising aplurality of entity computers each with means to provide an uniqueentity identification (ID) and a system server computer interconnectedby a communications network, the system server computer having an escrowaccount associated therewith into and out of which funds may betransferred, the method comprising establishing, prior to or during afunds transfer, an entity account for each entity computer with thesystem server computer and on a funds transfer being desired between twoentity computers, designating, as appropriate, one as a remittercomputer and the other as a receiver computer and then the steps areperformed of: the remitter computer sends transaction details and thereceiver entity ID to the system server computer; the systems servercomputer generates two different codes, namely, a locking code and afunds release code, in which the locking code is used to control theholding of the funds in the escrow account and the funds release code isused to control the release of the funds from the escrow account; thesystems server computer confirms, by sending the locking code and fundsrelease code to the remitter computer, the availability of funds in theescrow account for the receiver computer entity account; and theremitter computer sends the locking code to the receiver computer andthe receiver computer sends the locking code to the systems servercomputer which locks the funds for that receiver computer so that thefunds are no longer available to the remitter computer; and in which ona specified event occurring, the funds release code is sent to thesystem server computer and the system server computer releases the fundsfrom the escrow account to the receiver computer entity account.
 53. Amethod as claimed in claim 52, in which on the system server computerconfirming the availability of the funds in the escrow account, thesystem server computer sends the two codes to the remitter computer andif the remitter computer does not send the locking code to the otherentity but sends it to the systems server computer, the transaction iscancelled and the funds in the escrow account are released to theremitter entity account.
 54. A method as claimed in claim 52, in whichthe sending of the funds release code to the system server computercomprises: the remitter computer sending the funds release code to thereceiver computer; and the receiver computer sending the funds releasecode to the system server computer.
 55. A method as claimed in claim 52,in which the specified event comprises one or more of: the expiry of anagreed settlement date; the receipt by the receiver computer ofacceptance of completion of the transaction; a prior agreed conditionprecedent for completion of the transaction being achieved; a mutuallyagreed outcome notified by the two entities to the systems servercomputer; and a decision by an arbitrator appointed to resolve thedispute.
 56. A method as claimed in claim 52, in which the establishmentof an entity account for a remitter computer is accomplished as part ofthe transfer of funds to the escrow account.
 57. A method as claimed inclaim 52, in which during the transaction, the remitter computerdisputes the satisfactory completion of the transaction prior to anexpected settlement date, the steps are performed of: the remittercomputer sends a revised settlement date to the system server computer;the two entity computers enter into dispute resolution negotiations; andif, on expiry of the revised settlement date, a satisfactory resolutionof the negotiations has not taken place with the release of the funds inthe escrow account to one or both of the entity accounts: the systemsserver computer establishes an appropriate formal alternative disputeresolution (ADR) procedure.
 58. A method as claimed in claim 57, inwhich on the revised settlement date expiring, a new revised settlementdate is set to allow negotiations to continue.
 59. A method as claimedin claim 57, in which after a preset number of revised settlement dateshave expired, the ADR procedure is initiated unless both entitycomputers agree to the setting of a further revised settlement date. 60.A method as claimed in claim 57, in which the system server computerrecords: the number of transactions for each entity computer, acting asa receiver computer; the reception of a revised settlement date for eachtransaction for that receiver computer as a default transaction; andwhere the number of default transactions exceed a preset limit, thesystem server computer removes the entity computer from the system. 61.A method as claimed in claim 57, in which the system server computerrecords: the number of transactions for each entity computer, acting asa remitter computer; the reception of a revised settlement date for eachtransaction for that remitter computer as a default transaction; andwhere the number of default transactions exceed a preset limit, thesystem server computer removes the entity computer from the system. 62.A method as claimed in claim 57, in which the sending of the fundsrelease code by the remitter computer to the systems server computerpermits the remitter computer to revise the settlement date.
 63. Amethod as claimed in claim 60, in which the preset limit is one or moreof: a number of default transactions in a specified period; a percentageof the total number of the transactions within a specified period beingdefault transactions.
 64. A method as claimed in claim 52 wherein eachindependent step is adapted to be sequentially carried out between twoor more jurisdictions.
 65. A funds transfer method in a systemcomprising a plurality of entity computers each with means to provide anunique entity identification (ID) and a system server computerinterconnected by a communications network, the system server computerhaving an escrow account associated therewith into and out of whichfunds may be transferred, the method comprising establishing, prior toor during a funds transfer, an entity account for each entity computerwith the system server computer and on a funds transfer being desiredbetween two entity computers, designating, as appropriate, one as aremitter computer and the other as a receiver computer in which thesystems server computer and/or the receiver computer are outside thejurisdiction, and then the steps are performed of: the remitter computersends transaction details and the receiver entity ID to the systemserver computer; generating two different codes, namely, a locking codeand a funds release code, in which the locking code is used to controlthe holding of the funds in the escrow account and the funds releasecode is used to control the release of the funds from the escrowaccount; from the systems server computer, the remitter computerreceives confirmation that the receiver computer has been notified ofthe availability of funds in the escrow account for the receivercomputer entity account, which funds are no longer available to theremitter computer; in which on the system server computer confirming theavailability of the funds in the escrow account, the remitter computerreceives a funds release code from the system server computer andconfirmation that a locking code was sent to the receiver computer; andthen on a specified event occurring, the funds release code is sent tothe system server computer instructing the system server computer torelease the funds from the escrow account to the receiver computerentity account.
 66. A funds transfer method in a system comprising aplurality of entity computers each with means to provide an uniqueentity identification (ID) and a system server computer interconnectedby a communications network, the system server computer having an escrowaccount associated therewith into and out of which funds may betransferred, the method comprising establishing, prior to or during afunds transfer, an entity account for each entity computer with thesystem server computer and on a funds transfer being desired between twoentity computers, designating, as appropriate, one as a remittercomputer and the other as a receiver computer when one or both of theentity computers may be outside the jurisdiction and then the steps areperformed of: from the remitter computer, the systems server computerreceives transaction details and the receiver entity ID; generating twodifferent codes, namely, a locking code and a funds release code, inwhich the locking code is used to control the holding of the funds inthe escrow account and the funds release code is used to control therelease of the funds from the escrow account; the systems servercomputer confirms the availability of funds in the escrow account forthe receiver computer entity account, which funds are no longeravailable to the remitter computer; in which on the system servercomputer confirming the availability of the funds in the escrow account,the system server computer sends the locking code to the receivercomputer and the funds release code to the remitter computer, and on aspecified event occurring, the funds release code is received by thesystem server computer and the system server computer releases the fundsfrom the escrow account to the receiver computer entity account.
 67. Afunds transfer method in a system comprising a plurality of entitycomputers each with means to provide an unique entity identification(ID) and a system server computer interconnected by a communicationsnetwork, the system server computer having an escrow account associatedtherewith into and out of which funds may be transferred, the methodcomprising establishing, prior to or during a funds transfer, an entityaccount for each entity computer with the system server computer and ona funds transfer being desired between two entity computers,designating, as appropriate, one as a remitter computer and the other asa receiver computer in which the systems server computer and/or thereceiver computer are outside the jurisdiction, and then the steps areperformed of: the remitter computer sends transaction details and thereceiver entity ID to the system server computer; generating twodifferent codes, namely, a locking code and a funds release code, inwhich the locking code is used to control the holding of the funds inthe escrow account and the funds release code is used to control therelease of the funds from the escrow account; from the systems servercomputer, the remitter computer receives confirmation that the receivercomputer has been notified of the availability of funds in the escrowaccount for the receiver computer entity account, which funds are nolonger available to the remitter computer; in which on the system servercomputer confirming the availability of the funds in the escrow account,the remitter computer receives a funds release code from the systemserver computer and confirmation that the locking code was sent to thereceiver computer and on a specified event occurring, the funds releasecode is sent to the system server computer instructing the system servercomputer to release the funds from the escrow account to the receivercomputer entity account; in which during the transaction, the remittercomputer disputes the satisfactory completion of the transaction priorto an expected settlement date, the steps are performed of: the remittercomputer sends a revised settlement date to the system server computer;the two entity computers enter into dispute resolution negotiations; andif, on expiry of the revised settlement date, a satisfactory resolutionof the negotiations has not taken place with the release of the funds inthe escrow account to one or both of the entity accounts: the systemsserver computer establishes an appropriate formal alternative disputeresolution (ADR) procedure.
 68. A computer program comprising programinstructions for causing a computer to carry out some or all of themethod of claim
 52. 69. A computer program according to claim 68,embodied on a record medium.
 70. A computer program according to claim68, stored in a computer memory.
 71. A computer program according toclaim 68, embodied in a read-only memory.
 72. A computer programaccording to claim 68, carried on an electrical signal carrier.
 73. Acomputer programmed to carry out some or all of the method of claim 52.